Abuse Reporting Format

The Abuse Reporting Format (ARF) is a standard format for reporting spam via email.

Contents

History

A draft describing a standard format for FBL reports was posted by Yakov Shafranovich in April 2005[1] and evolved to the current RFC 5965.[2] AOL, who pioneered the field in 2003, initially used a different format, and converted to this de facto standard in 2008.[3] Feedback loops don't have to use ARF, but most do.

In January 2010, the IETF chartered[4] a new working group working towards the goal of standardizing the ARF format. The new WG is called Messaging Abuse Reporting Format WG or MARF.

Purpose

The ARF format is designed to be extensible, providing for generic spam reporting, e.g. from users to some anti-spam center or help desk, or for opt-out operations. The format defines a new MIME type to be included in a multipart/report attachment, and includes at least the headers of the offending message. Although the draft description acknowledges that some operators may choose to modify or redact that portion for privacy or legal reasons, it recommends that the entire original email message be attached, including the unmodified recipient address.

An ARF-encapsulated FBL report comes with the same subject as the offending message. Much like bounce messages, an abuse report consists of a human readable part, followed by a machine readable part, and the original message. The machine readable part's type is message/feedback-report, whose definition is the core of the draft. Extensibility is achieved by including a Feedback-Type field that characterizes the report. Possible values of this field are

abuse spam or some other kind of email abuse;
fraud indicates some kind of fraud or phishing activity;
virus report of a virus found in the originating message;
other any other feedback that doesn't fit into other types;
not-spam can be used to report an email message that was mistakenly marked as spam.[5]

An IANA registry is provided for the Feedback-Type, as well as for the other field names.[6] Each field name may either be relevant for any type of feedback, or for a specified type only. Some fields may appear multiple times. For example, the Source-IP field, containing the IP address from which the original message was received, may appear in any type of FBL report, but only once; the Removal-Recipient field, indicating email addresses to be removed, may only appear in opt-out reports, but one or more times. In addition, there is a DKIM-Failure subtype, with its own IANA registry.

An example report for email abuse is as follows. (Note that only the first three lines of the machine readable part are required.)

  From: <abusedesk@example.com>
  Date: Thu, 8 Mar 2005 17:40:36 EDT
  Subject: FW: Earn money
  To: <abuse@example.net>
  MIME-Version: 1.0
  Content-Type: multipart/report; report-type=feedback-report;
       boundary="part1_13d.2e68ed54_boundary"
   
  --part1_13d.2e68ed54_boundary
  Content-Type: text/plain; charset="US-ASCII"
  Content-Transfer-Encoding: 7bit
   
  This is an email abuse report for an email message received from IP
  10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. For more information
  about this format please see http://www.mipassoc.org/arf/.
   
  --part1_13d.2e68ed54_boundary
  Content-Type: message/feedback-report
   
  Feedback-Type: abuse
  User-Agent: SomeGenerator/1.0
  Version: 0.1
  Original-Mail-From: <somespammer@example.net>
  Original-Rcpt-To: <user@example.com>
  Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
  Source-IP: 10.67.41.167
  Authentication-Results: mail.example.com
                 smtp.mail=somespammer@example.com;
                 spf=fail
  Reported-Domain: example.net
  Reported-Uri: http://example.net/earn_money.html
  Reported-Uri: mailto:user@example.com
  Removal-Recipient: user@example.com
   
  --part1_13d.2e68ed54_boundary
  Content-Type: message/rfc822
  Content-Disposition: inline
   
  From: <somespammer@example.net>
  Received: from mailserver.example.net (mailserver.example.net
       [10.67.41.167]) by example.com with ESMTP id M63d4137594e46;
       Thu, 08 Mar 2005 14:00:00 -0400
  To: <Undisclosed Recipients>
  Subject: Earn money
  MIME-Version: 1.0
  Content-type: text/plain
  Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
  Date: Thu, 02 Sep 2004 12:31:03 -0500
   
  Spam Spam Spam
  Spam Spam Spam
  Spam Spam Spam
  Spam Spam Spam
  --part1_13d.2e68ed54_boundary--

See also

References

  1. ^ Yakov Shafranovich (2005-04-14). "New Abuse Draft". Shaftek.org. http://www.shaftek.org/blog/2005/04/14/new-abuse-draft/. Retrieved 17 November 2008. 
  2. ^ John Levine (2010-09-01). "ARF is Now an IETF Standard". CircleID. http://www.circleid.com/posts/20100901_arf_is_now_an_ietf_standard/. Retrieved 12 September 2010. 
  3. ^ Christine Borgia (2008-06-27). "AOL Converting All FBLs to ARF on 9/2/08". AOL. http://postmaster-blog.aol.com/2008/06/27/aol-converting-all-fbls-to-arf-on-9-2-08/. Retrieved 17 November 2008. 
  4. ^ IETF. "MARF charter". http://www.ietf.org/dyn/wg/charter/marf-charter.html. Retrieved January 26, 2010. 
  5. ^ Kepeng Li; Barry Leiba (November 2011). "Email Feedback Report Type Value: not-spam". PROPOSED STANDARD. IETF. http://tools.ietf.org/html/rfc6430. Retrieved 11 November 2011. 
  6. ^ "Messaging Abuse Reporting Format (MARF) Parameters". Protocol Registries. IANA. 26 May 2010. http://www.iana.org/assignments/marf-parameters/marf-parameters.xml. Retrieved 29 November 2011.